feat!: replace hybrid CJS/ESM build with ESM-only - #9536

Remove CJS entry points (`main`, `types`, `require`) from all package
manifests and simplify `exports` to a single `import` condition. This
drops the dual CJS/ESM output in favour of ESM-only distribution.

Mark all packages (and the root) as native ESM by adding
`"type": "module"` to their manifests. Also adds a Yarn constraint
to enforce this field going forward.

`__dirname` is not available in ESM. Replace all usages with
`import.meta.dirname`, which is equivalent and available since
Node.js 21.2.

Older versions of TypeScript break when using named imports in ESM.
Import the default export and destructure instead as a temporary
workaround. Also passes `--formatter oxfmt` to the
`messenger-action-types` scripts in packages missing it.

Adding `"type": "module"` to every package made each `jest.config.js` an
ES module, so the `require` and `module.exports` they are written with no
longer resolved and Jest could not start at all.

Rather than convert the test setup to ESM, the configs move to `.cjs` and
Jest keeps running as CommonJS. A `ts-jest` transform override compiles
the sources to CommonJS for tests only, which leaves the published build
untouched. This works because Jest treats TypeScript as ESM only when the
extension is listed in `extensionsToTreatAsEsm`, which it is not here.

Keeping the tests on CommonJS avoids importing `jest` from
`@jest/globals` in every test file, swapping `lodash` for `lodash-es`,
and rewriting `jest.mock` calls as `jest.unstable_mockModule`. It also
resolves the failures where an external CommonJS dependency could not
`require()` a monorepo package that had become ESM-only.

The trade-off is that the suite exercises CommonJS while the packages
ship ESM, so genuinely ESM-only problems are caught by the build and type
checks rather than by the tests.

`"type": "module"` in the root manifest makes every `.js` file an ES
module, so `.prettierrc.js` could no longer use `module.exports`. It moves
to `.prettierrc.cjs`, and the entry point in `knip.config.mts` is updated
to match.

The `permission-controller` ESLint config is removed rather than renamed.
It extends a root `.eslintrc.js` that no longer exists now that the repo
uses flat config in `eslint.config.mjs`, and nothing references it, so it
has no effect.

The packages compile to CommonJS for tests, but the scripts cannot: they
use `import.meta`, which has no CommonJS equivalent. Their Jest config
opts into ESM instead, through `extensionsToTreatAsEsm` and the `useESM`
option of `ts-jest`.

Running as ESM means `require` and the injected `jest` global are gone, so
`utils.ts` loads the Prettier config through `createRequire`, and the test
files import `jest` from `@jest/globals`. `jest.mock` has no effect on ES
modules, so the mocked modules move to `jest.unstable_mockModule` and are
pulled in with dynamic imports afterwards.

The `process.exit` spy in `cli.test.ts` now has to be installed before
`cli.js` is imported. The ESM build of yargs captures `process.exit` by
reference when it loads, so a spy installed later is never consulted, and
its implementation is re-armed per test because `resetMocks` clears it.

`lodash` is CommonJS, so its named exports cannot be imported from an ES
module: `import { cloneDeep } from 'lodash'` throws at run time once the
packages are loaded as ESM. This went unnoticed because the tests compile
to CommonJS, where the same import is fine. It surfaced in the
`wallet-cli` daemon end-to-end test, which spawns the built CLI and so
loads the real ES modules.

The sources now import `lodash-es`, which publishes the same API as an ES
module. Jest maps it back to `lodash` for the tests, since the reverse
problem applies there: an ES module cannot be `require`d.

Two call sites needed more than a rename. `smart-transactions-controller`
imported the default export, which `lodash-es` does not provide, so it
imports the functions it uses by name. `assets-controller` referred to the
`MemoizedFunction` type, which `@types/lodash-es` does not re-export, so
it takes that type from `@types/lodash` instead; the import is erased at
compile time and adds no run-time dependency.

`ethereumjs-wallet` is CommonJS, and Node cannot reliably detect its named
exports, so `import { thirdparty }` throws once the package is loaded as an
ES module. Node 22 fails on it where Node 24 happens to cope, which is why
this only appeared in the `wallet-cli` daemon end-to-end test.

The package also declares a TypeScript-style default export, so
`module.exports` is reached through `default` under Node's interop but is
the namespace itself once `esModuleInterop` has unwrapped it for the
CommonJS test build. Both shapes are now resolved explicitly, which also
fixes `Wallet.fromV3` being `undefined` under ESM.

Support for Node 18 and 20 was dropped in #9168, which set `engines` to
`^22.14.0 || ^24` and trimmed the test matrices, but the `wallet-cli`
daemon end-to-end job kept its own matrix and was missed. Node 20 also
lacks the ESM interop these packages now rely on.

The build info files record which outputs `tsc` has already produced, so
deleting `dist` without them leaves the two disagreeing. Incremental builds
then skip work whose output is gone, which surfaces as a cascade of TS6305
"has not been built from source file" errors that a clean build does not
resolve.

Under `moduleResolution: "Node16"`, TypeScript decides whether a
declaration file is ESM or CommonJS from the nearest `package.json`
`"type"` field. `@metamask/safe-event-emitter` declares no `"type"`, so
its ESM declarations were read as CommonJS and the default import
resolved to the module namespace rather than the class, leaving
`class JsonRpcEngine extends SafeEventEmitter` failing to build.

That was carried as a patch adding an `index.d.mts`, which TypeScript
always treats as ESM. Version 3.1.3 ships the same fix, so the patch and
its resolutions are removed in favour of the released version. Pinning to
a patched `3.1.1` would also have silently dropped the fix as soon as
anything asked for a newer version.

…-controller`

`lodash-es` is already a dependency of this package for other uses, so
`klona` was an unnecessary second deep-clone implementation. Using
`cloneDeep` avoids the extra dependency.